In “open” computing systems there is a need from time to time to add and remove applications available from various application design vendors without requiring pre-knowledge of each of the applications while still allowing the applications to co-operate such that the overall system remains functional and also to allow communication between these applications. For example, in interactive voice response (IVR) applications there are many ‘routine’, or infrastructure, operations that must be performed on every connection. Some of these infrastructure type operations are, for example, identifying and authenticating the caller, applying ring tone, applying ring-back tone, detecting answer, detecting that a called party is busy, call supervision, connection tear down, etc. While these common operations are routine and repetitive in nature they are not necessarily easy to create or manage for those not familiar with the communication network. In addition, some applications may or may not be present depending on the features that have been plugged into the system. The system must be able to cope with this and provide methods for applications to query what applications are available.
In particular, in IVR applications it is desired to maintain common language and common prompts across applications, and it is imperative that the interaction between the user and the application be consistent across all the available applications. Also, when applications are designed by different vendors, i.e., in a pluggable environment, the application designer (vendor) does not know what group (or sub groups) of menu items a particular user might want, or be entitled to. This then leads to inconsistency across pluggable applications from different vendors. Thus, if different users are allowed access to different applications (or different features of an application), then each user's menu must be changed in accordance with which applications are selected to be available to the user. Again, this presents a problem when the applications are not designed by a common entity. This requires some method by which an application can be added to a system so that the existing prompts and menu structures remain valid.
Another problem exists in that different users prefer to have different sets of applications. Thus, some users always want their banking prompts to start with a request for a banking balance because that user typically does not use the IVR system for banking functions other than to obtain a balance. Similarly, a user calling an airline, for example, might always wish to hear the gate number of any departing flight he or she is booked on for that day while another caller may always wish to be given arrival times of certain flights. Other users may wish to be able to find both their bank balance and gate number via the same phone number and navigate to the information they desire.
Another problem for telephone users is the fact that the interface from different vendor's applications often result in different and often confusing user instructions. For example, one application might require a user to input a “1” to signify agreement, while another application might require the user to input a “1” followed by a “#” before it will recognize the “1”. Other applications might want the user to say “yes” while still other applications might want the user to say “accept” instead of “yes”. Some applications desire numbers, such as credit and numbers, to be input with spaces while others will not accept spaces. While seemingly trivial, these differences compound to make system navigation difficult. Problems similar to these have been addressed in U.S. Pat. No. 6,246,989, where device specific functions are provided to a user depending, in part, upon the context of the user's device at the time of the prompt.
Additional problems exist when it is required to bill customers for use of various services. Adding such billing control to an individual application adds a high amount of sophistication and logistics to an already complicated application.